クラスメソッド新卒1年目の業務・働き方をご紹介します（数字も添えて）

クラスメソッド新卒1年目の業務や働き方を、かなり詳細にご紹介していきます。稼働に関するありったけのデータも集めて可視化してみました。

#採用

#ポエム

#キャリア

#会社紹介

#働き方

春田拓海 | Takumi

2020.04.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。DA事業本部の春田です。

クラスメソッドに新卒入社してから1年が経ちました。内定を頂いた時に部長から言われた言葉が今でも忘れられません。

「DA事業本部の新卒一号として、君は重要なサンプルだから」

そう、私は部の新卒サンプル第一号なのです。なのでサンプルはサンプルらしく、最後までサンプルでありたいと思います。

各プロジェクトでやってきたこと

各案件の業務内容についてご紹介していきます。

某配信サービスのリアルタイムデータ分析基盤構築

入社月の4月から6月までは、某配信アプリのリアルタイムデータ分析基盤を構築している案件にアサインされました。ゴリゴリのサーバレスアーキテクチャを使うこの案件は、部署の中ではかなり異端な方です。主に使っていたリソースは以下の通りです。

AWS Lambda
AWS Step Functions
Amazon CloudWatch
Amazon Aurora
Amazon DynamoDB
Amazon S3
Amazon SQS
Amazon SNS
AWS CloudFormation
AWS X-Ray
AWS CodeCommit
AWS CodeBuild
AWS CodePipeline

モダンなマネージドサービスをフル活用した設計だったので、AWSに慣れるにはもってこいの案件でした。また、サーバレスの楽しさもこの時知りました。Step Functionsはまじで楽すぎる。

ざっとBacklogを見直したところ、以下のような実装を担当していました。太字の上4つが割としっかりめの内容で、それ以外は細かいタスクをひたすら捌いていました。受託案件ながらも準委任という契約形態のおかげで、自由度高くやらせてもらえたのが良かったですね。

ジョブの実行結果をSlackチャンネルに通知する
Step FunctionsでAthenaのクエリ実行をコントロールする
無料版Slackのメッセージ数制限をなんとかするLambdaの作成
新規APIサーバーから流れてくる日次データのETL処理構築
Lambda・Step Functionsのログ出力の調節と強化
Auroraのデータライフサイクルを管理するLambdaの作成
SQLやServerless YAMLのリファクタリング
サービスの監視で使うメトリクスの洗い出し
Serverless Frameworkの各種プラグインの調査
バグ調査、改修に伴う影響範囲調査

ジョブの実行結果をSlackチャンネルに通知する

Slackの通知機能……。そうそれは、システム側のロジックに全く影響ないけどあったら嬉しい機能という、まさに新人にもってこいのタスクです。ほぼ初心者で案件にアサインされた場合は、間違いなく皆さんも通知機能を実装していると思います(笑)。簡単そうに見えて、意外とSlack Appの認証方式とかが細かくて苦戦するんですよね〜。アサインされたての4月に実装していた機能でした。

Step FunctionsでAthenaのクエリ実行をコントロールする

Step Functionsに慣れようということで、非同期のAthenaをワークフローで処理するためのステートマシンを構築しました。先輩が別のアプリで実装していたアーキテクチャを丸パクリすれば間違いないだろう、と思って同じような作りにしたら「素晴らしい」とお褒めいただきました。平和な世界で良かったです。こちらも4月の実装です。

無料版Slackのメッセージ数制限をなんとかするLambdaの作成

Slackの無料版ってメッセージ数の限界があるので、機械的に通知しまくっていると他のチャンネルのメッセージが読めなくなってしまうんですよね。それをかなりセコい方法で解決するLambdaを作成しました。セコすぎて笑えてくるので、ブログにしています。5月の実装でした。

新規APIサーバーから流れてくる日次データのETL処理構築

6月に入って、いよいよETL処理の構築を担当させてもらえるようになりました。要件整理から設計、実装までやった初めてのタスクで、かなり面白かったです。ざっくりいうと、LambdaでAPIを叩いてデータを一旦S3に置き、jqで変換してAuroraにInsertするというワークフローをStep Functionsで書くという内容でした。大変だったのは、クライアントの要望を汲み取るのが難しかった要件整理と、APIサーバーの仕様が特殊すぎてLambda上で簡単には扱えなかった、という点です。大変でしたが、ロジックを組んでいくプロセスがかなり楽しかったです。

ビッグデータ分析用のDWH構築

7月に入って、ビッグデータ分析用のデータウェアハウスを構築している案件にアサインされました。これぞデータアナリティクス事業本部！といった感じで、ゴリゴリにRedshiftを使います。EC2にPython製のワークフローを配置して、RedshiftやRDSに対してデータを捌いていく、よくあるDWHですね。

Amazon Redshift
Amazon EC2
Amazon RDS MySQL
Amazon S3

コード上では小さな変更でも影響範囲はかなり広く、テストに時間がかかるタスクが多かったです。一つ一つがかなり重く、例えば1つのカラムをテーブルに追加するだけで、影響範囲の確認に3週間は必要とするシステムでした。また、他のメンバーは沖縄と岡山にいるという、クラメソらしいチームだったなと思います。Wow!

実装内容は以下の通りです。

軽減税率対応
Redsfhitのテーブルチューニング
新しく追加されるマスタデータやカラムのELT処理を実装・修正
AuroraのSSL/TLS証明書更新

軽減税率対応

2019年10月から適応された軽減税率に際して、一部のテーブルにカラムが追加される変更がありました。変更箇所自体は大したことないのですが、リポジトリ内に大量にある他のワークフローへの影響確認が大変だったり、単体テスト・内部結合テスト・外部結合テストを行う入念なテストフローだったり、「システムを作ってるんだな」って一番実感した案件かもしれません。データ量も膨大だったので、単体での実行に数時間かかるワークフローもあったり、なんとなく「身動きが取りづらいなぁ……」とも感じていました。ただその後のタスクは、これと似たようなものが多かったので楽ちんでした。

Redshiftのテーブルチューニング

この案件で技術的に1番勉強になったのは、Redshiftのチューニングです。10月以降はDBチューニングの沼にどっぷりと浸かってました。Redshiftはソートキーだけでなく、データをどうノードに分散させるかを決める分散キーもあるので、チューニングパターンが結構複雑だったりします。Compound SortkeyとInterleaved Sortkeyの細かすぎる特徴を整理し、自分で検証も繰り返しましたが、年末のRedshiftの内部処理改善によって、その知見が無に帰することとなった時は泣きました。クラウド時代のDBチューニングは、シンプル・イズ・ザ・ベストです。ベンダー側の改善にあやかりましょう。

せっかくなので、AWS大薗さんの超ありがたいスライドを置いておきます。

Amazon Redshift Deep Dive & Update

某サブスクリプションサービスのデータ分析基盤構築

12月から現在までは、某サブスクリプションサービスのデータ分析基盤構築に携わっています。この案件はS3に配置したファイルデータを、Athenaでクエリするデータレイクっぽいアーキテクチャです。マネージドサービスはあまり使わず、EC2上のDigdagでワークフローを制御しています。

Amazon S3
Amazon Athena
Amazon EC2
AWS Lambda
AWS API Gateway
Amazon SQS

フランクに濃いタスクが振られてきます。また、弊社側はチームで動いているわけではなく、クライアントと私でほぼ一対一です。まだまだ甘いところはありますが、ようやく一人立ちできたのかな？と思いたいです。

Redashバージョンアップに伴うコンテナ化
CIによる自動テスト&本番デプロイ
SlackのSlashコマンドでDigdag APIを叩く
データ変換処理改善・リファクタリング

Redashバージョンアップに伴うコンテナ化

データを可視化するBIツールにRedashを使っているのですが、新機能やバグ改善のためにバージョンアップしたいとのことでした。ただ、OSSのRedashは最近のバージョンからコンテナ化したこともあって、どうすれば何も問題なくデータが移行できるかの検証を重ねてました。需要ありそうだったので、ブログにしています。

CIによる自動テスト&本番デプロイ

リリースした最新バージョンを、本番環境にデプロイする方法が手動だったので、Digdag上でワンクリックでデプロイできる機能を実装しました。CI/CDをスクラッチで実装する難しさを知り、GitHub Actionsに恋い焦がれました。併せてスクラム手法に合うようなGitブランチ戦略を考えちゃったりして、色々ルールを決めてしまった自分が今でも怖いです。

スクラムのGitブランチ戦略は、以下を参考にしました。今のところ特に不便はないです。

SlackのSlashコマンドでDigdag APIを叩く

SlackのSlashコマンドで、Digdagジョブを実行させる機能を作りました。今回はプライベートなEC2インスタンスのDigdag APIを叩くために、API Gatewayを噛ませました。Slashコマンド → API Gateway → VPC Lambda → Digdag APIといった感じです。API Gateway上の認証をどうするかに苦戦しました。汎用性高いので、後日ブログにできたらと思います。

データ変換処理改善・リファクタリング

ユーザーログの急増によってデータを処理しきれないジョブがあったりしたので、それの処理改善やリファクタリングを行いました。大体の原因が、メモリを食いすぎるpandasなんですよね。こんなにPythonのジェネレータを意識して開発したことは今までなかったです。

数字で見るわたしの実績

昨年度1年間の稼働時間を折れ線グラフにしてみました。有給休暇も8時間として換算しています。データの特性上、少数桁の最大値は6です。

合計	平均	最小	最大	稼働日数
1913.56時間	8.14時間	6時間	11.1時間	236日

１日15分くらいしか残業してませんでした。月の労働時間で帳尻が合えばいいので、定時前にあがることも結構多かったです。

次にプロジェクトごとの稼働時間も見てみます。

	プロジェクト1	プロジェクト2	プロジェクト3	ちょい役サポート	会社業務	ブログ執筆
4月	131	0	0	0	28	9.5
5月	119.75	0	0	0	15.5	20
6月	126.5	0	0	14	6.5	16.5
7月	0	148.5	0	0	17	20
8月	0	140.5	0	0	12	20.5
9月	0	134.5	0	0	4	15.5
10月	0	126	0	0	29	16
11月	0	126	0	0	12.5	19.5
12月	0	1.0	49	0	53.5	18
1月	0	0	121.5	0	24	8.5
2月	0	0	109.5	23	11	16.5
3月	0	0	115.5	7.5	27.5	24
合計	377.25	676.5	395.5	44.5	240.5	204.5

1年間で携わったメインの案件は3つで、大体3ヶ月スパンで回っていました。これらが稼働時間全体の約75%を占めています。「ちょい役サポート」というのはスキマ時間に手伝った他のプロジェクトに当たります。全社イベントなどの会社業務は合計240時間ですが、他の会社に比べたら少ないのでしょうか？業務中のブログ執筆時間は、大体月10〜20時間でした。

書いたブログの実績を見てみます。

re:Invent2019のレポートを書きまくった12月の14本が最高で、普段は頑張った月で4本、最低2本は書けるよう努めていました。昨年度はねた記事は6本で、技術系とそうでないので半々。これ以外にも気合い入れて書いた記事はありますが、ニッチ過ぎてあまりバズらなかったり。

その他の取り組み

角川ドワンゴ学園N中等部取材企画

「新卒だけど何か自分で企画持ちたいな〜」と思い、1年かけて連載取材企画を進めてきました。「なんでクラスメソッドが角川ドワンゴ学園と関わってるの？」と疑問に思う方がいるかと思いますが、この企画は僕の好奇心のみで動いていて、僕の方から学園に協力をお願いしている企画です。取材に協力いただいている生徒さんご家族、学園側の先生方だったり、企画書作成から交渉まで色々アドバイスをくれた弊社のマーケ部だったり、多くの人を巻き込んでいる企画なので、とりわけ思い入れが強いです。

何より、角川ドワンゴ学園が展開しているカリキュラムって本当にユニークで面白いんですよ。生徒や先生と話していると、僕のワクワクは止まることを知りません。良かったら読んでみてください。最終回は近日上がります。